User Community

• GNU General Public License GPL
• GNU Definition
• Open Source Initiative

These notes are much more important in an open community like OpenCPN. Otherwise work issues tend to be out of sight, and we risk that two or more are working on the same thing, clueless of each other. Open cooperation and problem solving communication is a much better way.

Also there is a wide range of skills & skill levels in this community. We all try to help each other, but we need to understand that this is all voluntary, and intended to be fun. We all share the common interest of supporting and creating great Chart Plotter Navigation software. OpenCPN is very lucky to be supported by some very talented individuals too, contributing their time and skills to the program. Won't you help in some way too?

There are many ways to participate in and assist this Open Source Project. Programming skills are advantageous but not necessary because many other different skills and efforts are needed. See where you can help!

1. Language Translator: Assist by Crowdin Translation of OpenCPN and Plugins
2. User Manual Editor: Assist by Editing the Manual
3. User Support: On OpenCPN Cruiser's Forum help others learn OpenCPN and provide answers.
4. Plugin Testing: Test new and updated plugins and report errors and successes.
5. OpenCPN Testing: Testing new versions of OpenCPN before and after release.
6. Find Bugs!: All Users should report bugs, repeatable actions to recreate, and detailed reports.
7. Report Bugs and Request Features using Tracker . To reach the Flyspray Trackerfrom the OpenCPN Web pages click on the “Tracker” tab at the upper right (above the blue bar). The sticky thread Tracker/Flyspray - How and When to use it gives some hints.
8. Provide User Feedback: Suggestions, User Interface Suggestions, Feature Requests, Bugs should be done via:
   • OpenCPN Cruiser's Forum Find or make an appropriate thread For discussion.
   • Tracker Sometimes called Flyspray. You must register first.

Note:

1. Please refrain from inserting your comments, bugs & feature requests into Alpha and Beta Testing.
2. This distracts programmers, disrupts communications, and the points, as good as they may, be are generally lost!
3. Programmers often work on bigger projects than the User Interface, associated with multiple OS, migration to newer tools, big new features..
4. Let the programmers work in peace on tough problems.

Beta Testing is conducted in a Real Time environment (not using Debug) by volunteer Testers or end users when the development team determines the software is ready.

Any user can be a beta tester, they need to know how to install and use the software and report. Using CI tools is inappropriate for Beta Testing.

Done early on by skilled testers at the specific request of programmers who are actively creating big new features or internal optimizations. These skilled testers are asked by the programmers to help achieve the main goals of the program to get it ready for Beta Testing, using a “Debug” environment. They do not “Bug” the programmers with:

1. Additional feature requests.
2. UI changes.
3. Known Bugs (the programmers already know about)
4. Other trivia.

They debug the program using their software tools and report the actions and error codes using MSVC++ call stack, or Linux debug tools. Beta testing can only begin when the development team is sure there are no obvious bugs such as null pointer deref or other errors that can be caught through testing inside a debug environment. Beta testing begins when the development team wishes it.

However do not “bug” the programmers. Simply report your findings as completely as possible using the Github “Issues” section if possible. Include any pertinent logs, screenshots or files. Do not combine issues into one post and identify the program version or date.

Programming skills vary greatly. Some are learning, some have many years of experience. Respect each other and work together when possible.

We unfortunately don't have manpower to teach people programming and duplicate every piece of documentation out there.

Dave has suggested these websites for Training in C++ which is the most basic skill required. In any case they should be bookmarked and studied.

• LearnCpp
• CSplusplus
• Github Opensource Getting Started

We also do not have energy, time, resources, whatever, to maintain the outdated toolchain, dependencies and know-how. However all the build instructions are updated for the current master and that is what developers should use. Versions other than the current Release are just history!

Debugging see the “Compiling” pages“

• Linux Compile & Debug - GNU Data Display Debugger Webpage Intro to DDD Manual
• Windows Compile & Debug - Windows Debuggers
• Compile & Debug on MacOS

Online Repositories - Free to Opensource

• Github Opensource Help Getting Started OpenCPN Github Plugin Repositories
• Sourceforge OpenCPN Older compiled OpenCPN
• Sourceforge Packaging Data Necessary for Compiling
• Sourceforge Older Plugins Older Plugins

Additional Software Tools which integrate with and push to Github - Free to OpenSource :

• Travis CI “Build apps with confidence”
• Appveyor “Continuous Integration solution for Windows” Docs

1. Programmers use these tools to setup automatic builds of the current github “head”. This involves having certain *.yml files in the main directory and requires the plugin author to have an account and enable the feature. Linux and Windows executable become available for download and testing.
2. OpenCPN and some plugins have TravisCI and Appeveyor enabled.
3. Alpha Testers working closely with Programmers can then access and download the most recent “build” without having to compile.
4. These tools are used for ad hoc “Alpha Testing”.
5. OpenCPN Programmers do not use these tools for Continuous Integration (CI) or Continuous Releases (CR) or Test Driven Development (TDD).

See Advanced Debugging Tips